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(54) Dynamic extension of print capabilities 

(57) A utility that defines additional attributes that 
would cater to a user's needs provides dynamically ex- 
tended printing capabilities. The system architecture al- 
lows the information to be pushed down transparently 



to the receiving end, which understands the semantics 
of the given information. System administrators can de- 
fine information to monitor for accounting purposes, etc. 
The utility allows additional printer features to be incor- 
porated without disrupting the existing system. 
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Description 

[0001] The invention relates to dynamically extending 
printing capabilities using dynamic object identifiers. In 
particular, this invention is directed to enabling a user to 
define additional attributes without having to modify ex- 
isting software. 

[0002] The enterprise print management systems 
provide the means to control and access various print- 
ers and to manage other related information remotely. 
However, in the current systems, the extent to which 
these functions can be utilized is limited by the fixed set 
of predefined system attributes. Attributes are collec- 
tions of data that describe the entities that compose the 
print management system. For example, printer at- 
tributes may describe the various printing features that 
users may use to produce high-quality documents, or 
they may describe status or configuration information, 
such as printer's state or location. Hence, when new 
printers, with new features not defined by existing print- 
ing standards, become available in the marketplace, the 
users cannot readily access these features via outdated 
print management system. And consequently, the print 
management systems vendor must upgrade the soft- 
ware and redistribute it to their customers. 
[0003] This invention provides a method and appara- 
tus to dynamically extend printing capabilities through 
the use of dynamic attributes and syntaxes. By using 
dynamic attributes, the system administrators may de- 
fine additional attributes that would cater to their site- 
specific needs (e.g. accounting), and the printer vendors 
may plug-in the new features to the print management 
system without any disruption. In addition, these dynam- 
ic attributes may take values with syntax that do not ad- 
here to the current standard. 

[0004] A file format is defined to describe the new at- 
tribute, its OID (globally unique "object identifier"), and 
the syntax of its values. The new attributes can be read- 
in and registered into the system through a system ad- 
ministration function while the system is down, or auto- 
matically without bringing down the system. A unique 
algorithm is used to break-down the complex attributes 
into components using simple Document Printing Appli- 
cation (DPA) -defined syntaxes. 
[0005] These and other features and advantages of 
this invention are described in or are apparent from the 
following detailed description of the preferred embodi- 
ments. 

[0006] The invention is described in detail with refer- 
ence to the following drawings, wherein like numerals 
represent like elements and wherein: 

Fig. 1 is a diagram showing the interaction between 
the client, server and printer; 

Fig. 2 is a diagram showing the flow of document 
data in a print request 

Fig. 3 is a diagram showing the flow of attributes in 
detail; 



Figs. 4 and 5 are diagrams showing the methods of 
introducing dynamic attributes to the system; 
Figs. 6 A and 6B is a flowchart outlining how the dy- 
namic OlDs are processed; 
5 Fig. 7 is an example of ASN.1 syntax for a new fea- 
ture of newly released printer; and 
Fig. 8 is the pseudo C structure for the example in 
Fig. 7. 

to [0007] Attributes define or characterize print manage- 
ment system's abstract entities, or objects. For exam- 
ple, document attributes, such as plex, margin, orienta- 
tion, etc., describe how the printed material should ap- 
pear. Printer Attributes, such as media-ready, fonts- 

'5 ready, etc., describe the available resources or features 
of the printer. In addition to these attributes, there are a 
suite of attributes to facilitate end-user, operator and ad- 
ministrator functions. In summary, attributes are a set of 
data that describes the objects of the print management 

20 system. 

[0008] There are three basic elements to an attribute: 
an object identifier (OID), a syntax and a value. An OID 
is a globally unique identifier of an attribute which is cod- 
ed such that it may be understood by all printing sys- 

25 terns. The OlDs are allocated following a tree format, 
such that each printer vendor or standards organization 
is assigned a branch of this tree. Then each organization 
may assign unique OlDs by further branching out. For 
example, the OID of "job-owner" is 1.0. 101 75. 1.3. 1.3 in 

30 the ISO 10175 standard for Document Printing Applica- 
tions (DPA). If the server receives the "job-owner" at- 
tribute, the server can store the attribute or send this 
information to an account log upon completion of a print 
job using the OlDs, for example. Then, an accounting 

35 program written by a third party vendor can easily inter- 
pret the information in the accounting log through the 
OlDs. 

[0009] The syntax of an attribute is the format in which 

the attribute value is represented. For example, the syn- 
40 tax of the "job-owner" attribute is "distinguishedName", 

which is an example of coded language the computer 

or printing system understands. 

[0010] The value of an attribute is the instance of the 

attribute. For example, the value of "job-owner" could 
45 be "John Jones", i.e., the name of the person to whom 

the print job belongs. 

[0011] Figure 1 is a diagram showing the interaction 
between the client 110, the server 120 and the output 
device 160. The output device is, for example, a printer. 

so The client 1 1 0 is the interface between the user and the 
print management system. A spooler 122 takes print re- 
quests from multiple clients 110, schedules print jobs 
based on the print requests and then forwards the print 
jobs to a supervisor 124. The supervisor 124 provides 

55 the common interface between the spooler 122 and the 
output devices 160The supervisor 124 takes the print 
jobs from the spooler 1 22 and invokes the designated 
printer to render the data. 
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[0012] The client 110 may communicate directly with 
either the spooler 122 or the supervisor 124 regarding 
management requests. For example, the system admin- 
istrator may send a request to the supervisor 124 to 
modify the access control informatbn, or an end-user t 
may send a request to the supervisor 124 to see the 
current status of all the printers that the supervisor 1 24 
manages. These print requests and management re- 
quests basically communicate the characteristics of the 
objects of interest. In other words, the informatbn that 1 
flows between the client 11 0 and the server 1 20 are the 
attributes and the corresponding values of the objects. 
For instance, in a print request, the client 110 sends the 
document data along with document attributes and cor- 
responding values that dictate how to print, what printer i 
to use, who the job owner is, etc. For management re- 
quests, the client 110 may query the server 120 tor the 
information about the printers. The server 1 20 then re- 
turns the printer attributes and their corresponding val- 
ues that describe the status, location, available features, ■ 
etc. 

[0013] Figure 2 shows an overview of the flow of the 
document data and attributes in a print management 
system that utilizes the extended print capabilities. The 
object identifier (OID) databases 111 and 125 store the 
object identifiers of all the attributes that the print man- 
agement system supports. The attribute dictionaries 
(AD) 112 and 126 maintain the non-DPA syntax of any 
supported attributes. For every attribute that is not in 
DPA syntax, the complex syntax is broken down to com- 
ponents in DPA-syntax and stored in AD 112. Hence, 
given an attribute name or OID, the AD 112 returns a 
sequence of component names (or OID) and their DPA- 
syntax. The object databases (ODB) 127 and 129 that 
store the objects and their attribute-value pairs. The 
print data memory 1 28 is a temporary storage that keeps 
the actual contents of the document. The accounting log 
130 is a data file that contains the accountable print job 
information. 

[0014] When a user submits a print job by selecting 
documents, the printer and other attributes, the client 
110 puts together this data and sends it to the server 
1 20. The server 120 then reads the data and stores the 
document data in the print data memory 1 28 and creates 
a abstract entity, a job object, that contain the attributes 
specified in the data package from client 11 0 and stores 
it in the ODB 127. When the specified printer 160 is 
ready to print a new job, the server 120 retrieves the 
document data from the print data memory 128 and 
sends the document data to the specified printer 160. 
The server 1 20 also retrieves the job object attributes 
from the ODB 1 27, and based on these attributes, sends 
print controls to the specified printer 160. When the 
specified printer 160 completes printing of the document 
or printing is terminated for any other reason, (i.e. if it is 
canceled or aborted), the server 1 20 writes the account- 
ing information to the accounting log 130. 
[0015] Figure 3 shows in detail the flow of attributes 



and their corresponding values between the client 110 
and the server 1 20. When the user specifies an attribute, 
the client 110 queries its OID database 111 with the tex- 
tural name of the attribute. The object identifier (OID) 
> database 1 1 2 returns a globally unique identifier , such 
as the one discussed above for "job-owner 0 , i.e., 
1.0.10175.1.3.1.3, and the syntax. If the syntax is non- 
standard, then the client 1 1 0 further looks in the attribute 
dictionary 1 1 2 for the standard syntax components bro- 
o ken down. The attribute value specified by the user is 
then interpreted according to this syntax and is grouped 
with the OID that identifies the attribute. The ottribute- 
OID, value> pair is encoded and sent by the client 
across to the server 120. The server 120 queries the 
r5 OID database 1 25 and attribute dictionary 1 26 with the 
OID. Then based on the syntax, the server 1 20 puts the 
<attribute-OID, value> pair in the format that can be 
readily interpreted by the server 120. This is stored in 
the object database 1 27 as part of an object. 
20 [0016] Figure 4 and 5 describe how the dynamic at- 
tributes can be introduced to the print management sys- 
tem 100. First, the dynamic attributes and syntaxes are 
registered in the server's OID database 125 and at- 
tribute dictionary 126. When a user queries the server 
25 120 for the special attributes "xxx-supported attributes", 
where "xxx" is an object class, the dynamic attributes 
are then registered in the client's OID database 111 and 
attribute dictionary 112. From the users' point of view, 
there is nothing special about querying these attributes 
30 (i.e. querying the server is a standard function). Howev- 
er, the client performs the additional task of updating the 
databases 1 1 1 and 1 1 2 in the background. 
[0017] Registering dynamic attributes to the server's 
database 125 and the attribute dictionary 126 can be 
35 achieved in two ways. One is by running a system ad- 
ministrator tool 200 that reads in a data file 1 64 trust con- 
tains the attributes, OlDs and syntax. Another rpethod 
is an automated registration which reads in the* same 
data file (i.e., without shutting down the servers and us- 
40 ing the system administration function, above). The sys- 
tem administrator tool 200 should be run manually when 
the system is down. The system administrator tool 200 
registers the new attributes into the OID database 125. 
If the attribute syntax is non-standard, the system ad- 
45 ministrator tool 200 also registers the components of the 
attributes expressed in DPA-primitive types in the at- 
tribute dictionary 126. 

[0018] The automated registration varies slightly de- 
pending on the associated object class of the dynamic 
so attributes. Registering printer attributes will occur when 
newprinters are addedtothe system. Registering other 
object attributes will occur when the system administra- 
tor sets the "extended-attribute-file". Typically, the file 
pointed to by this attribute contains job or document at- 
55 tributes for management of site-specific accounting in- 
formation. 

[0019] Figure 4 illustrates how dynamic printer at- 
tributes are introduced to the system 100. When a new 
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printer is added to the system, the system administrator 
creates an abstract printer object that is mapped to the 
physical device. In the request to create this abstract 
printer object, the system administrator may specify an 
"extended-printer-attribute-file" (XPAFfile), which is the 
path to the file that contains the dynamic attribute 
names, the OlDs and the syntaxes. The server 120 
reads this XPAFfile, translates the information, and then 
stores the attribute-name and the OlDs in the OID da- 
tabase 125 and the non-standard syntaxes in the at- 
tribute dictionary 126, respectively. When the client 110 
queries "printer-supported-attributes", the server 120 
returns the names, the OlDs and the syntaxes of all 
printer dynamic attributes. The client 110 then updates 
its OID database 111 and the attribute dictionary 112. 
[0020] Figure 5 illustrates how dynamic document or 
job attributes are introduced. As discussed before, a 
standard management request includes setting or mod- 
ifying an attribute value of an object. When the system 
administrator sets "extended-attribute-file", the server 
120 reads the file pointed to by this path, translates the 
information and updates its OID database 125 and the 
attribute dictionary 126. Updating the client databases 
111 and 112 is the same as in updating the printer at- 
tributes, except in that the client 110 should query "job- 
supported-attributes" or "document-supported-at- 
tributes". 

[0021] Figures 6A and 6B are a flowchart illustrating 
how document attribute information is passed through 
the system to the printerl60. Figure 6A shows the doc- 
ument flow on the clientside. Figure 6B shows the doc- 
ument flow on the server side. 

[0022] Beginning at step S500, control continues to 
step S505, where the user specifies an attribute which 
has a corresponding attribute value. Next, at step S510 
the client 110 queries its OID database 111 with the tex- 
tural name of the attribute. At step S515, the OID data- 
base 111 returns the OID and the syntax to the client 
110. 

[0023] At step S520, the client 1 1 0 determines wheth- 
erthe syntax is standard (i.e., per DPA standards). If the 
syntax is non-standard, control continues to step S525. 
Otherwise, control jumps to step S540. 
[0024] At step S525, the client 110 queries the at- 
tribute dictionary 112 for the standard-syntax compo- 
nents that form the non-standard-syntax attribute. Then, 
at step S530, the attribute dictionary 112 returns the 
components and syntax to the client 110. Next, at step 
S535, the attribute components are translated into in- 
ternal representation and grouped into an ottribute- 
OID, attribute value> pair. The client 110 is then ready 
to process the next user-specified attribute. Control then 
jumps to step S540. 

[0025] In step S540, the attribute Ol D and the attribute 
value are paired and translated into internal represen- 
tations. Control then continues to step S545. At step 
S545, the client 110 determines if all attributes have 
been checked. If not, control returns to step S505. Oth- 



erwise, once all attributes with standard and non-stand- 
ard syntax are processed, control continues to step 
S550. 

[0026] At step S550, the client 110 encodes the <at- 
s tribute Ol D, attribute value> pairs and sends them to the 
server 1 20. 

[0027] In Fig. 6B, at step S555, the server 120 de- 
codes the data from the client 110. Then, at step S560, 
the OID and the syntax are decoded. Next, at step S565, 

10 the server 1 20 determines if the syntax is standard. If 
the syntax is non-standard, control continues to step 
S570. Otherwise, control jumps to step S585. 
[0028] At step S570, the server 120 queries its at- 
tribute dictionary 126 for the components broken down 

15 into standard syntax. Then, at step S575, the attribute 
dictionary 126 returns the components and the syntax 
to the server 120. Next, at step S580, the components 
are translated into internal representations and grouped 
into an attribute-value. Control then jumps to step S590. 

20 in contrast, at step S585, the attribute value is translated 
into an internal representation. Control then also contin- 
ues to step S590 

[0029] Thus, at step S590, the internal representation 
of the <attribute OID-attribute-value> pair is stored in 

25 the object database 1 29. Then, at step S595 when the 
document is ready to print, the supervisor 124 retrieves 
the document attributes from the object database 129 
and sends control signals to the printer 160 according 
to the attribute settings. Control then continues to step 

30 S600, where the control routine stops 

[0030] The following scenario illustrates how these 
dynamic OlDs function. Company X releases a new 
printer 162 that has the newfinishing feature expressed 
in ASN.1 syntax, as shown in Fig. 7. This finishing fea- 

35 ture is stored as part of the XPAF file 164. When the 
printer 162 is first connected to the system 100, the sys- 
tem reads the XPAF 1 64 file. The system 1 00 then trans- 
lates the feature into a pseudo-C structure, as shown in 
Fig. 8. 

40 [0031] A data structure denoting this complex syntax 
is stored in the attribute dictionary 1 1 4, and is retrievable 
at run-time. The client 1 1 0 can retrieve this attribute and 
use the information to build the globally unique identifier 
at run-time to allow the user to manipulate the dynamic 

45 attribute. 

[0032] As shown in Figures 3-6B, as well as in the ex- 
ample outlined above, the implementation of dynamic 
OlDs is preferably performed on a programmed general 
purpose computer. However, the implementation of dy- 

50 namic Ol Ds can also be performed on a special purpose 
computer, a programmed microprocessor or microcon- 
troller and peripheral integrated circuit elements, an 
ASIC or other integrated circuit, a hardwired electronic 
or logic circuit such as a discrete element circuit, a pro- 

55 grammable logic device such as a PLD, PLA, FGPA or 
PAL, or the like. In general, any device on which a finite 
state machine capable of implementing the flowchart 
shown in Figs. 6A and 6B and the example illustrated 
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above, can be used to perform the implementation of 
the dynamic OlDs. 



Claims 

1. A system for providing dynamic extension of print 
management capabilities, comprising: 

a first processor that receives an input signal 
containing dynamic attributes and sends the 
corresponding attributes to a second proces- 
sor; and 

the second processor that receives the trans- 
mitted dynamic attributes from the first proces- 
sor and performs actions based on the received 
dynamic attributes; 

wherein the first processor receives the dynam- 
ic attributes back from the second processor 
and translates the dynamic attributes into a us- 
er-recognizable form. 

2. The system of claim 1, wherein each dynamic at- 
tribute has an object identifier, a syntax and a value. 

3. The system of claim 1 or claim 2, wherein the first 
and second processors encode the Ol Ds. 

4. A system according to any of claims 1 to 3, wherein 
the first processor further comprises: 

a first memory containing textual names of the 
dynamic attributes and the dynamic attributes' 
corresponding OlDs; and 
a second memory containing internal represen- 
tations of the syntaxes of the dynamic at- 
tributes. 



returning the dynamic attributes back to the first 
processor; and 

translating the dynamic attributes into a user- 
recognizable form. 

s 

7. The method of claim 6, wherein each dynamic at- 
tribute received has an object identifier (OID), a syn- 
tax and a value. 

10 8. The method of claim 6 or claim 7, further comprising 
encoding the OlDs. 

9. The method of any of claims 6 to 8, further compris- 
ing storing textual names of the dynamic attributes, 

is the dynamic attributes' corresponding OlDs, and in- 
terna! representations of the syntaxes of the dy- 
namic attributes. 

10. The method of any of claims 6 to 8, further compris- 
20 ing storing textual names of the dynamic attributes 

and the corresponding OlDs, the internal represen- 
tations of the syntaxes of the dynamic attributes, 
and the OlDs of the dynamic attributes and their val- 
ues. 

25 



30 



35 



5 The system of claim 4, further comprising: 

40 

a third memory containing textual names of the 
dynamic attributes and the corresponding 
OlDs; and 

a fourth memory containing internal represen- 
tations of the syntaxes of the dynamic at- «s 
tributes; and 

a fifth memory containing the OlDs of the dy- 
namic attributes and their values. 

6. A method for providing dynamic extension of print so 
management capabilities, comprising: 

receiving an input signal containing dynamic at- 
tributes at a first processor; 

sending the corresponding attributes to a sec- ss 
ond processor; 

performing actions based on the received dy- 
namic attributes; 
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